Both Media Gateway Controller (abbreviated as MGC) and Media Gateway (abbreviated as MG) are key components in a Next Generation Network (NGN). The MGC provides call control function, while the MG provides service bearing function, thereby implementing separation between the call control plane and the service bearing plane, sharing network resource efficiently, simplifying upgrading of devices and service expansion, and greatly reducing the costs of network deployment and maintenance.
FIG. 1 illustrates the relation and communication protocols among components of the NGN. In the figure, the core packet network is usually an Internet Protocol (abbreviated as IP) network, which provides the connections between MG and MG as well as the connections between MG and MGC. MG is responsible for enabling a user terminal to access the core network through an access network. The MGC communicates with the MGs using media gateway control protocol, thereby providing the control of MG under MGC and network control function. Communication between MG and MG is adapted for accomplishing the bearing of media streams, and is usually implemented using Real-time Transport Protocol (abbreviated as RTP).
Media gateway control protocol is a major protocol between MG and MGC. At present, two media gateway control protocols are widely used, i.e., H.248 (also called MeGaCo protocol) and Media Gateway Control Protocol (abbreviated as MGCP). The MGCP was published in October 1999 and revised in January 2003 by Internet Engineering Task Force (abbreviated as IETF). H.248 protocol was published in November 2000 and revised on June 2003 by IETF together with International Telecommunication Union (abbreviated as ITU).
In H.248 protocol, MGs bear traffic through resources in the MGs. Various resources in MGs are abstracted as terminations. The terminations are categorized into two major classes: physical terminations and ephemeral terminations. The former represents some semi-permanent physical entities, such as Time Division Multiplexing (abbreviated as TDM) channels. The latter represents some public resources that are obtained on request temporarily and then released after being used, such as RTP streams. Any combination of different terminations is abstracted as context. A context may include multiple terminations. And the relationship among terminations may be described in terms of topology. Based on such an abstract model, the call control may be indeed described as various operations and processing on terminations and contexts.
In the media gateway protocol communication, MGCs interact with MGs through commands. Each command carries parameters that are categorized into signals, events, etc. A signal is used by MGCs to instruct MGs to perform operations on resources, such as send dial tone, ring-back tone, or busy tone to a subscriber. The events are used by MGCs to instruct MGs to perform state monitoring, such as monitoring of off-hook, hang-up, dialing, and flash-hook of a subscriber.
Commands such as signals and events contain various control details of MGs in call proceedings and operations on resources. Therefore, the commands should be executed in strict sequence. However, the uncertainty and lack of reliability of IP networks may result in out-of-order transmission of commands and even the loss of commands, which may bring severe errors. Therefore, in the media gateway protocol communication, a mechanism should be adopted to ensure that commands can be transmitted and executed in sequence.
In H.248 protocol, a mechanism called transaction has been adopted for the transmission and execution of commands. Correlation of commands is defined with transaction, i.e. commands within a transaction are executed in sequence, while commands within different transactions may be executed in parallel. In addition, the execution sequence of commands within different transactions follows the rules as follows:
Rule 1: Commands addressed to different terminations may be sent in parallel.
Rule 2: For transmission without an ensured transmission sequence, e.g. User Datagram Protocol (abbreviated as UDP), there should be at most one unfinished command of Notify in H.248 protocol in one termination.
Rule 3: An AuditValue command in H.248 protocol is not limited to any sequence.
Rule 2 ensures that operations on a termination can be performed in sequence. Because each command must be responded with a Notify, Rule 2 also ensures that the next command will not be executed until the current command is responded. The AuditValue command is a special command for returning a current state of termination characteristic and has no conflict with any other operation. Therefore Audit Value command is not limited to any sequence.
Based on the above three rules, a receiver of a command is a separate executing unit in terms of transaction. If there are multiple commands within a transaction, the commands should be executed in sequence. However, commands between different transactions may be executed in a sequence of reception or executed in parallel by ignoring the sequence. Therefore, if there is a correlation among commands, a command sender must effectively ensure the executed sequence of commands at a receiver in accordance with a rule.
When an MGC sends a command to an MG, MGC should ensure that there is at most one unfinished command (Add, Modify or Move) in H.248 protocol in one termination. For MGC capable of controlling a call proceeding, the next command is sent after a previous command is responded. Therefore, viewed from the command sent from MGC to MG, MGC can realize the control of sending sequence of events without a complex mechanism.
However, for MG, it should be ensured that there is at most one unfinished command of Notify in H.248 protocol in one termination when MG reports events to MGC. Most of the information that is reported to MGC by MG is users' operations, such as off-hook, hang-up, dialing and flash-hook in voice service. Because users' operations are usually random, MG should establish a more complex mechanism than that of MGC to ensure that the commands from MG itself can be executed in MGC serially without producing any out-of-order fact. The mechanism for implementing sequential report of events at MG is called Light Weight State Machine.
The method of reporting events by MG is a key issue, a hot issue and also a difficult issue at present in NGN network technology.
At present, in the art, there are mainly two technical solutions for addressing the issue of processing events reported by MG. One is a technology based on reliable transmission protocol, and the other is a technology based on control by MGC.
The first solution adopts transmission protocols based on reliable connection, such as Transfer Control Protocol (abbreviated as TCP) and Stream Control Transmission Protocol (abbreviated as SCTP), to ensure the sequential and serial transmission of commands, so that it can be ensured that a receiver can perform sequential execution due to the sequential transmission at a sender. An application layer of the sender only needs to deliver a command message to be sent to a transmission layer, so that the reliability mechanism of transmission protocols is adopted to ensure that each message can reach the receiver sequentially. Before the previous command is responded, a subsequent command will be buffered in a sending queue of the transmission layer. In such a manner, the mechanism of buffering at the transmission layer and serial sending of commands can achieve the object of serial execution of commands.
The first solution, by adopting the transmission protocols based on reliable connection, can avoid out-of-order execution of commands due to transmission, but at the same time the first solution limits the transmission protocol that can be selected by the application. Particularly, this solution is not adapted for such an environment in which unreliable connection should be widely used. In addition, the reliability mechanism of the transmission protocols will reduce the transfer rate of messages, and thereby resulting in a reduced interacting efficiency of commands definitely.
The other solution based on MGC control adopts an EventBuffer mechanism to ensure the commands as serial, i.e. if a termination does not receive a response of Notify in response to an event report, subsequent events detected are temporarily buffered in a First In First Out (abbreviated as FIFO) queue established for this termination based on certain selection conditions, and the terminal selects the comments from the queue for report in accordance with certain conditions after receiving a response to the previous event, while those comments that can not meet the selection conditions will be discarded. However, H.248 protocol adopts Events Descriptor to set report conditions of the events, adopts EventBuffer Descriptor to set buffer conditions of the events, and adopts EventBufferControl property to control the FIFO queue for buffering events to be off or to perform a one-time selection and event report (LockStep) in accordance with the conditions of Events Descriptor. Therefore, the procedure of reporting events is controlled through sending Events Descriptor by MGC.
In this solution, by the use of EventBuffer Descriptor and Events Descriptor, the above three rules can be met. If requiring an MG to detect and report some specific events, an MGC creates an Events Descriptor containing the specific events and sends the Events Descriptor to MG. A general Events Descriptor has a one-time report limit, i.e. events in the Events Descriptor are in a locked state (i.e. will not be used) after detected and reported. If requiring MG to detect and report another event, MGC has to send a new Events Descriptor. Once the events in the Events Descriptor are detected, MG reports the events to MGC through a command of Notify. Prior to receiving a response of Notify from MGC by MG, the command of Notify maintains in an unfinished state. In accordance with Rule 2, if a further event comes at this time, the event has to enter an EventBuffer for this termination to be buffered, until MG receives a response to the command of Notify from MGC. If there is an active Events Descriptor, MG continues to obtain events for report from the EventBuffer in accordance with a rule.
This solution can ensure serial transmission and execution of commands by adopting the EventBuffer mechanism, but the start of this mechanism with a high complexity in MG has to depend on the fact that MGC has to send a control in advance. However, in practical applications, it is necessary for only MG to ensure serial command report. In addition, if too many events are accumulated in the FIFO queue, the one-by-one detection and report manner will greatly reduce the interaction efficiency of commands between MG and MGC. In practical applications, many of these accumulated events are invalid events indeed. It causes rather serious trouble if the invalid events are reported to MGC, which results in the waste of time and the reduced processing efficiency. In an extreme case, this will badly affect the synchronization of termination state information between MG and MGC.